Under the direction of experienced and knowledgeable people, software can help doctors identify the source of an ailment, help banks handle millions of transactions accurately, help students search digital libraries, help artists tell stories and engineers build safer structures, and do a thousand other things to entertain, protect, and assist us. Despite the shortcomings of computer technology, automation and other uses of software have generally made the world a better place by facilitating advances in medical research, civil engineering, telecommunications, and other areas that touch our lives daily in a thousand ways we often take for granted. Nonetheless, software is far from perfect.
For an average consumer, one of the most frustrating trends in software development and commercialization has been the tendency for software programs to include more and more features over time. This tendency is sometimes called “feature creep” and examples are sometimes referred to as “bloatware.”
Bloatware requires ever larger amounts of hard disk and RAM storage, and ever faster processors. Even worse, it burdens program users with a growing tangle of commands and options and preferences and other features, often symbolized by blocks of buttons, icons, tabs, menu items, and other visual paraphernalia. Some of the new features in word processors, spreadsheets, communications software, and other widely used applications may be useful to many people. But more often than not, people use only a small fraction of the features available in a given program. The rest of the features are just inconvenient noise in one's mental map of the software and wasted space on one's disk or in system memory.
Several approaches have been tried to reduce the problems caused by continually adding new features to programs. One approach replaces arcane commands and command line options, such as those used in UNIX or DOS operating system command interpreters, with graphical user interfaces of menus, folders, and other metaphors, like those used in the Apple Macintosh and Microsoft Windows environments. This makes it easier to identify commands and other features, since one can look them up by flipping through menus instead of committing them to memory. But a program's menu hierarchy can still become quite large and confusing as additional features and corresponding menu commands or state variables (sometimes called “options” or “preferences”) are added to the program.
More generally, many studies have been done to determine the desirability of different user interface designs. For instance, mouse-driven designs have been compared with keyboard-driven designs and with designs that use a combination of keyboard and mouse input. Different color combinations have also been tested. Some of these design attempts have included user models, logs, or other means for recording the behavior of an individual user for subsequent analysis by the interface designers.
Some user interface designs would replace mouse-driven menus with a voice-driven interface, whereby the user enters commands and data by speaking it instead of using a mouse, light pen, keyboard, touch-screen, or similar input device. This could require users to once again begin memorizing the commands they wish to use, or else make it necessary to look up commands with some help facility. Alternatively, a voice-driven interface could require sophisticated speech recognition and natural language interpretation capabilities. Neither approach directly addresses the problem of “wasted” features, namely, program capabilities which are not needed by a given user and thus consume storage space, processor cycles, and other resources without benefiting that user.
Another approach simply provides users with smaller programs containing fewer features. In some cases, such a minimalist program is accompanied by a promise that the vendor's efforts will be put into making the existing features faster, more accurate, more efficient, more reliable, more readily available, and so forth, instead of putting limited development resources to work on new features. An unspoken (or sometimes spoken!) assumption is that other vendors add features simply to justify a new release to generate additional revenue.
Providing users with a small but carefully selected feature set is a worthwhile approach to reducing bloatware. Unfortunately, not everyone agrees on which features belong in a minimalist program's reduced feature set. Feature creep seems almost inevitable, either by continual expansion of the minimalist program or by abandonment of it altogether in favor of a larger program that has one or more desired features which are not found in the minimalist program.
Yet another approach focuses on making the interface itself adaptable or customizable by users. For instance, users may be allowed to change color palettes, modify menus, create macros, and/or to hide or reposition toolbars. Some of these customizations could be used to reduce interface complexity.
But customizing an interface does not necessarily reduce interface complexity, much less reduce program size. For instance, macros may be additional features rather than substitute features, so that they actually increase the feature set presented to the user. Toolbar and menu visibility control is only helpful if the interface features are grouped such that a user wants to see all of them or none at them at a given time. The process of hiding features or making them visible must also be easy and convenient.
Moreover, even when customized interfaces hide features from immediate view, the underlying code to implement those features is still part of the program. The program itself is not any smaller. It simply appears at first glance to have fewer features.
An approach to feature selection which is used by many software vendors involves gradual classification of program features through feedback provided by the program's users. This feature selection process begins with the design, implementation, and debugging of the first version of the program. The program is released to users, and sooner or later the vendor receives and reviews comments from the users. In response, the source code is modified, the executable is rebuilt and debugged, and the new version is released. Comments on the new version are received and reviewed, the source is modified again, and the cycle of revisions and new versions continues. Initially the program's users are the program designers and the programmers themselves. Later, the users include alpha and beta testers, and finally, they include people who paid for the right to use the software. Over the course of several (sometimes many) versions, the vendor learns which features are the most popular, and modifies the program accordingly.
However, selecting features based on user comments in this manner has several major drawbacks. First, it can take months or even years. Second, because the process takes so long and is subject to influence from so many sources, the feature set may never stabilize. Third, a user who frequently uses a feature which is not popular with other users may lose access to that feature in a new version. This is particularly frustrating if the new version contains improvements not found in the current version, forcing the user to choose between the improvements in the new version and the frequently used feature in the old version. Finally, for a variety of reasons, many vendors have historically chosen to add features far more often than they chose to remove them, leading to the present bloatware problem.
Extensive efforts have been directed toward making it easier to add code to an existing program. Patching and other dynamic reconfiguration techniques; software components ranging from COM and OLE and OpenDoc components to *.DLL files to Java components to Ada and Modula-2 packages and modules; better networking in general and electronic software distribution in particular; enlarged hard drives and falling hardware prices; and improved software development environments and tools all make it continually easier to add code and features to software. Although the ability to add features and the ability to fix bugs with little or no intervention by users can be beneficial, these abilities do not address the problem of dealing with features that are unwanted or unneeded by a given user.
Software is used in various contexts to gain information about various types of user preferences. For instance, the usage of an entire program or a software component such as a Java applet may be monitored to permit metered licensing based on the number of concurrent users of the program or component and/or the length of time during which copies of the program or component are loaded for execution. Such monitoring provides a general indication about the popularity of the program or component as a whole, but it does not say much about a given user's thoughts concerning individual features.
In another context, software agents, cookies, demographic databases, and other means are used to track user preferences on books, music, discussion topics, and other things. Sometimes the information is merely used for targeted marketing; sometimes it is used to make guesses about which products a user might like. Regardless, however, this approach does not track individual software features to determine which ones are wasted from a given user's point of view.
In yet another context, programmers use tools such as debuggers and profilers to identify sections of source code that consume large amounts of processor time or other resources, so that opportunities for improved efficiency are more readily identified. However, any resulting changes are made in a master copy of the program which is eventually distributed to many users, so individual user preferences are not addressed.
In short, it would be an advancement to provide a new approach to software design which promptly and conveniently provides software users with the functional features they desire, without burdening their computers and their minds with unwanted features. Such an approach is disclosed and claimed herein.